HPAVC/HPAVC CD-ROM.iso/CIS_GAME.ARJ/QFOFX1.THD

Text File | 1993-07-01 | 55KB | 1,117 lines

_________________________ Subj: Flights of Fantasy _________________________

Fm: Mitchell Waite 75146,3515                  # 332701
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 13-Apr-93  11:19:14

Today fractal landscapes in Rescue on Fractalus are pretty poor when compared
to Comanche as far as realism is concerned. I know that guy that wrote the
ROF fractals.

It would be fun to add a chapter in the sequel to FOF that shows how to do 3D
landscape generation following the Comanche approach, that is prestoring
height info and finding a way to reconstruct the original terrain. But before
that I would like to see FOF take on some simple polygon mountains and
terrain like the kind used in Falcon 3. Then I'd like to see some bit mapped
mountains.

Speaking of wish lists, here is mine:

1. Outside the cockpit views.
2. More items on the ground and an editor for building your own gound
objects.
3. Enemy planes, wingman, and engagement.
4. More weapons and a weapons editor.

Anybody got another other ideas/requests/wishes?

Mitch
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 332757
To: Mitchell Waite 75146,3515 (X)              Date: 13-Apr-93  12:35:46

RESCUE ON FRACTALUS was awfully impressive in its day. Nobody'd ever done
anything like that before. Of course, that was the better part of a decade
ago and it was written on an 8-bit machine, so it looks kinda crude now. But
it demonstrated basic principles that are still being explored by programmers
in the 1990s!

There's no question that the FOF sequel should include COMANCHE-style
landscape representation, though I suspect it will require more than one
chapter. And, yes, there should be more done with polygon mountains. This
won't require too much new technology over the first FOF, just more work on
the scenery database. What's really needed is the program I never quite got
working in FOF, to generate complex mountain shapes. I've got some new ideas
about that one, so maybe this time I'll get it up and running. And an editor
for designing ground objects would be great to include, though simply
designing a user interface for such a program is a subject worthy of its own
book!

My wish list also includes polygon smoothing, using either Gouraud or Phong
shading (or modified versions thereof), a subject I suspect there'll be great
enthusiasm for among the crowd in this forum. Gradient-fill horizons would
also be fun to play around with. Although I discuss horizons at some length
in FOF, adding the gradient would add an interesting and exciting new level
of complexity to an already complicated task.

Bitmaps are another topic that can be covered at _incredible_ length! In
fact, there could be a completely separate book in that one (though I've got
dibs on writing it!). STRIKE COMMANDER looks like it's about to introduce a
whole battery of new techniques, many of them having to do with rotated
bitmaps. Most importantly, there's an entire new genre of bitmapped dungeon
games now attaining unbelievable popularity -- ULTIMA UNDERWORLD, WOLFENSTEIN
3D plus several upcoming shareware and commercial games that are going to
blow people's socks off! The excitement over these games has been quite
palpable among the game designers in this section. I'd love to do a
_parallel_ sequel to FOF concerning these things. (Perhaps it could be called
Dungeons of Dread?) This would allow me to discuss the various kinds of
texture mapping -- vertical post, three-dimensional -- and their application
to interior maze exploration games. And I've got an idea for a _great_
chapter on monster animations! <g>

As for the FOF sequel, there could be an entire _section_ covering the
airplanes themselves -- external views of planes, combat systems, multiple
airplanes, aerial combat sequences. And perhaps, instead of modelling a
simple propeller driven plane as in FOF, the sequel could concentrate on
jets. A HUD could be added to the cockpit view, with the ability to lock onto
targets, follow them on radar, launch missiles, etc.

Other possible topics: Mode X animation, SVGA animation, Truecolor (24-bit)
animation, VESA programming, use of XMS and EMS to store data, and (if
Borland updates their compiler to handle it) full 386 protected mode
programming.

Yeesh, what am I getting myself into?! <g>

--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 333188
To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 13-Apr-93  22:14:17

The key point about the raycasting is that the scenery is strictly
two-dimensional; only height values for terrain "points" (the grid elements)
are stored. So when you look across the terrain at an angle, what you see is
the differences in heights between terrain points, as vertical lines. As a
ray crosses a straight-line sequence of these terrain points, a vertical line
is drawn each time in the current screen column to represent the difference
in height (the "rise," if you will) between each terrain point and the one
beyond it. Perhaps a different color could be used for the top pixel of each
"rise" to differentiate it from the side of the rise, to give a light-sourced
effect.

This is hard to explain without a picture. Taking a good look at the COMANCHE
screen helps. Have you played it? There's a demo over in GAMAPUB LIB 16 if
you haven't. Search on the keywords NOVALOGIC or COMANCHE.

Yes, it would look pretty nifty in 320x200x32K, but not enough people have it
yet to make it viable for a game. Heck, the graphics board I've got in my
machine currently can do 320x200x16M, which would look _really_ neat! (And
would be _really_ slow! <g>)

--Chris
...........................................................................

Fm: John Dlugosz [ViewPoint] 70007,4657        # 333277
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 14-Apr-93  00:25:34

<<So when you look across the terrain at an angle, what you see is the
differences in heights between terrain points, as vertical lines.>> So what
_color_ is it?  That is, what's the surface normal?  Looking at a nest of
vertical poles will give me a solid blank wall of uniform color.

<<slow>> manipulating 16-bit pixels is _faster_ than 8-bit pixels if done one
at a time.  I would buffer strips and write a whole pixarray at once, so it
does translate to a speed difference.  But I don't think the extra writes are
significant compared to the other processing.

I'm thinking of a demo and example, not a full game!  If it makes you dizzy,
so much the better <g>.

I kind of like my tent-pole ideas.  Wonder how fast I can get it?

How about higer res than 320x200?  Even if not good for realtime animation,
it means I can redislay the surface I'm viewing from any angle in a small
fraction of the time it takes with the method used in SURFACE/SHOW that I
think I sent you.

For each point in the field, I need a height value and 6 colors.  Be lavish
and figure 13 bytes each.  That means 400K would be good for 31K points, or
177 points square.  The mountain in my SURFACE program is 128 square.  Sounds
doable.
--John
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 333456
To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 14-Apr-93  10:06:08

I'll have to go back and reinstall the COMANCHE demo to think about the color
business. I assume that the colors are determined in advance, since the
terrain never moves and therefore never has to be re-lightsourced (unless the
sun is assumed to be moving through the sky, which isn't really necessary).
Thus, shadow and light effects could be precalculated and stored in the
array, if there's room. Some "vertical poles" will be dark, some light, most
somewhere in between. A hell of a lot of work to precalculate and store, yes,
but the effect should be worth it. Of course, I already see the flaw in this:
what if a pole is half in light, half in shadow? How do you store that? Like
I said, I'd better go reinstall COMANCHE (as soon as my taxes are done <g>).

Try to hold your res down to 640x480, because that's all my current monitor
can handle. BTW, I was unable to run that fractal mountain demo you sent me,
because it wants to run at a higher res. Is there a command line switch I can
use to get it down to 640x480? (If all you guys will keep buying copies of
FLIGHTS OF FANTASY, I promise to invest a chunk of the royalties in an SVGA
monitor! <g>)

--Chris
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 333013
To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 13-Apr-93  19:38:20

I've been thinking about raycasting, too. The basic cut of it that I
understand is that you cast a ray from the POV to each pixel of the 320
vertical columns (or whatever number is visible), stopping at the first
location in the x-z plane that has a feature in position to occult the ray.
You then draw a pixel at that point in the appropriate color. Height data is
a 2d array of y offsets. I imagine some sort of highly optimized 3D
Bresenhams could be used to cast the ray.

                                                --Mark
...........................................................................

Fm: John Dlugosz [ViewPoint] 70007,4657        # 333173
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 13-Apr-93  21:58:58

No, you will not cast from a single POINT of view through each pixel in the
screen.  Rather, you will make all the rays paralell, not meeting at a point,
passing through each pixel.

Anyway, imagine a bunch of telephone-pole-like objects of various lengths.
The top surface is the x-z point and the pole is elevating it in y.  Your ray
hits the side of the pole, not the top.  What color to make it?  It just
doesn't make sence.

Instead, stretch a rubber sheet over the poles and nail it down in the middle
of each one.  this causes a bunch of flat triangles to appear.  Each one of
these can be colored ahead of time.  _this_ is what I want to intersect with.

So, back to the first pole image.  There are 6 triangles meeting at the top
of the pole.  Based on which pole I hit and the direction I was coming from,
I identify the triangle.

Hmm, since the direction is always the same, 6 colors per pole is enough, and I
figure out which one ahead of time and use it for all 64,000 casts. That's
it!!

Thanks, I understand it much better now.

--John
...........................................................................

Fm: shmuel cohen 70431,1617                    # 332968
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 13-Apr-93  18:34:24

Good job!  I'll go back through the joystick stuff - but probably not tonight -
I just spent the day on Uncle Sam's stuff - and boy did I take it up the ol'
!@#$@.   Anyway, after I recover from my comatose state I'll dig into the
joystick stuff.

BTW, one last optimization on the Pcx::Display routine - add the screen.h
header file to the pcxclass.h and
then replace the Pcx::Display() function with this:

void Pcx::Display()
{
   blitscreen ( image );
}

By using Mark's blitscreen, we get a further improvement of 10% on my
machine, probably more on others.

This process might also make an interesting sidebar in a future addition -
especially if you have another section on optimizations - going from you For
loop to memove to Mark's asm routine.
...........................................................................

Fm: Mark Phillips 73167,3216                   # 332662
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 13-Apr-93  10:05:26

Chris,

 I am slowly working my way through FoF. First, Chapter 2 is the clearest
explanation of 3d math I've ever seen. Perfection!

 I found some typo's though. In ch. 3, at the top of pg. 73 you say the
function number of a video BIOS call goes in AL, and the code fragment says
the same thing. Listing 3-1 has it correct, with the function number in AH.
Pg. 75 has a C code fragment with 13h in it, shouldn't it be 0x13? The text
at the top of pg. 82 has the same problem as pg. 73, AH and AL are reversed.
In listing 3-3 the comment doesn't match the code, the code is hardwired for
all 256 palettes while the comment indicates it should pass parms for
FIRSTREG and NUMREGS. Finally, (g) the Table 5-1 says the joystick read
function is 16h, should be 15h.

 All minor problems. I'm a real beginner at C (I'm trying to convert FoF to
PowerBasic), so any code typos were certainly missed by me.

 Thanks again for the great book!

mjp
...........................................................................

Fm: David K. Morton 70750,1105                 # 333069
To:  76711,301 (X)                             Date: 13-Apr-93  20:15:07

Chris:  I bought the book on Flights of Fantasy last weekend and decided to
try to compile it on my machine.  The Make facility stoped at the file
drawpc.cpp. Is this in the book someplace or on the disk?  I could not find
it in or on either.  Could this be in the library.  Thanks in advance. Dave
Morton 70750,1105.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 333145
To: David K. Morton 70750,1105 (X)             Date: 13-Apr-93  21:28:50

Looks like I renamed a file without updating the makefile. (I was using the
Borland PRJ file myself.) Best way to fix this is to edit the makefile so
that DRAWPC.CPP will read DRAWPOLY.CPP instead. If that doesn't work, get
back to me right away, and I can probably suggest some alternative fixes.

Thanks for catching that! Yet another change for the next printing!

--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 333481
To: All                                        Date: 14-Apr-93  11:12:39

For those of you who have purchased my book FLIGHTS OF FANTASY, I just wanted
to mention that a bug has been reported in the program OPTDEMO.EXE, which
illustrates optimization concepts discussed in Chapter Nine. This is the
program that rotates shaded cubes and pyramids. Although the rotation works
just fine, the scaling functions (operated by the + and - keys) do not work.
If you use them, the cube swells beyond the proportions of the viewport,
trashing memory and locking up the machine. (Cute, right? <g>) This is a
version control problem: The version that was _supposed_ to go into the book
should have had the scaling functions disabled, since clipping code had not
yet been introduced in the book at this point and could not be used to
prevent memory from being clobbered.

The solution? Don't use the scaling controls! <g> I'll post another version
shortly with these controls disabled.

For those who have not yet purchased the book, don't worry. This problem
doesn't affect the flight simulator -- or any of the other programs in the
book. But it creates quite a spectacular visual effect right before it
crashes your machine! ;-)

Sorry about that one, folks!
...........................................................................

Fm: Hans Peter Rushworth 100031,473            # 337130
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 18-Apr-93  21:09:25

>> I'm struck by the difference between the crystal clear bowl in which most
flight sims operate, and the film footage I've seen. There's a atmospheric
hazy quality to most of it that the sims haven't reproduced.

That's true, conversely, on clear, bright, sunny days (or when you're above
the clouds) there is an intensity to the light that you cannot reproduce on
film, or on a display screen (unless you have a projector and you look into
the lenses!). Under these circumstances sunglasses are mandatory. It is
virtually impossible to see another aircraft if it is flying "out of the
sun". In fact it is most often VERY hard to see the other aircraft when it is
below you against the ground. Let alone flying through cloud. It is also
surprisingly difficult to pickout things like runways that are designed to be
easily seen.

It's no accident that excellent vision is a mandatory requirement for pilots,
especially in the military.

Haze is a factor, but the sun, ground complexity and clouds are perhaps more
significant, in my (limited) experience.

I'm not sure I would agree that speckle is an accurate model for haze or fog.
Distant objects "become grey" and/or "lose spatial resolution", but they
don't get "noisy" (like untuned TV), or do they? The "mirage" shimmering
effect on hot days occurs only if you are close the ground (I think).

Of course I don't mean to suggest the dithering or similar methods are not
appropriate in solving problems in computer graphics.

Peter.
...........................................................................

Fm: rod lentz 71163,57                         # 337952
To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 20-Apr-93  01:16:44

>> integer sqrt()

    The integer sqrt() method I'm current using is based upon Newton's
method of successive aproximations; in asm, it's the fastest I've
tested yet for the 386+ cpu's.  I believe that two versions from me,
and several others from other contributors went into the "wolf3d.thd"
that was just u/l'ed.  If it's not in there & you want specifics, let
me know & I'll send it over.

>> and distances via table trig

    My most frequent use of table trig so far is for calculating 2d
distances without sqrt()s.  This is using a table of pre-calc'ed
cos (atan ())'s.  The elements are currently stored as rationals
(numer, denom), which can also be treated as vectors.  I'll probably
change these over to fixed point soon.
    I've just started adding a few more similar trig tables for
some special uses.  I've got tables all over the place !

    BTW, tables are also great for _quickly_ doing simple image
processing on "packed rgb pels" (mapping an rgb cube in 256 color
mode).  Mixing, adding, &c.; although the memory overhead is quickly
rising <g>.
...........................................................................

Fm: Hans Peter Rushworth 100031,473            # 337471
To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 19-Apr-93  13:03:58

John,

>> I sent stuff that uses 256 color, and a mode13h driver.  This records my
experiments.

Yes, got it (twice <g>), thanks.

I did some tests using your ideas in my own shading routines. It's very
sucessful in removing the ring artifact where the difference between shades
is very small (ie if you have a lot of shades), but with larger intensity
differences it is less good (you then end up with wider, albeit unfocussed,
rings). It seems that the diffusion depth between regions needs to be a
function of the difference between available shades for a given surface.

I'll play with it a little more and see if I can get better results for this
situation.
...........................................................................

Fm: Hans Peter Rushworth 100031,473            # 337526
To: Hans Peter Rushworth 100031,473 (X)        Date: 19-Apr-93  15:40:02

Ok, simply adding a small fixed amount of noise cures this problem. The
amplitude of noise needs to be reduced for the surfaces that are rendered
with a colour that has more palette shades allocated to it to prevent those
surfaces looking noisy. In essence:

  pixel_intensity += (distinct_shades > 16) ? rand() & 3 : rand() & 7;

The results are surprisingly good, and let you get away with fewer shades
(and hence giving you more free colours in your colour map).

Mark: If you want a SHADE update which has this dither option, just ask.

Peter.
...........................................................................

Fm: rod lentz 71163,57                         # 337538
To: Hans Peter Rushworth 100031,473 (X)        Date: 19-Apr-93  15:52:48

    John - I played with the sample; looks good !  Still looks a little
slow for real-time, though.
    In my experience, if you have enough [spatial] resolution, adding
noise of +-1 target level does a good job of minimizing rings &
similar artifacts.  +-0.5 probably gives a more technicly accurate
dither, but subjectively I find less preferable.
    Also, if you have enough spatial resolution, dithering _all_
shades, even "pure" ones in the palette, looks good.  It gives a
slightly pointilistic effect, but one I like.  If high enough res,
spatial integration does a great job with this effect.
    Let me dig around; if you want, I'll send out a copy of my
"noise diffusion" dithering.
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 337927
To: Mitchell Waite 75146,3515 (X)              Date: 20-Apr-93  00:41:43

I believe that is the problem, Mitch, yes. FoF was developed on machines with
FPU's, and while it was tested on machines without them, it was not tested to a
great enough extent that I could make a representation. I was afraid that the
emulation would prove to be very slow, and sadly that fear has manifested
itself in reality. The lesson is to implement your own fixed-point math and
stay away from the emulator.

                                                        --Mark
...........................................................................

Fm: Mitchell Waite 75146,3515                  # 337888
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 19-Apr-93  23:43:37

How about this for scenery direction algorithms. Look at Gary Yost's 3D
Studio IPAS routines, particularly Silicon Gardens' plants, trees, and other
nature schrubs. They make plants and plants and terrain have a lot in common.

Another idea is to find some equations to simiulate wrinkles. Ding! I think
POV Ray has a wrinkles function. I know it can generate a texture that goes
inside an object. Perhaps one could use POV Ray to generate a large wrinkled
bit map 2D image. Then a program could be written to process the color info
to represent height. (Details could be drawn with POV Ray into the bit map in
any size if you wanted zooming.) Then figure out how to get the viewers POV
on the screen at 14 fps :)
...........................................................................

Fm: rod lentz 71163,57                         # 337978
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 20-Apr-93  01:44:46

    It's a rare occasion I ever use the emulator.  For years, I've
been jumping through hoops (as most others) to use int's, rationals
and fixed points.  Now, it's so ingrained that I rarely use floats,
even if the app isn't time critical & I know it will only be run on
my (486dx) machine.
    Also, I was once writing a tsr in msc, and discovered that my
one use of floating point (addition only) caused the entire emulator
to be included.  At about 11k, it was an awful lot of overkill for
that little use, and I switched to fixedp.

         - Rod
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 338169
To: Mitchell Waite 75146,3515 (X)              Date: 20-Apr-93  11:31:53

Wrinkles would be yet another fractal feature (and probably as slow as the
rest <g>). Does POV ray generate the wrinkles or is it working from a
pre-existing bitmap? Sounds like it would be easier to get FRACTINT to
generate something like that and work backwards from it. Best of all, I'll
just look at the source code to both of'em and see what I can steal, er,
learn from. ;-)
--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 347021
To: Ian Christie 70534,403                     Date: 03-May-93  14:16:52

There are some problems with three of the programs. WAITE.EXE _does_ cause a
memory allocation error, OPTDEMO will crash if you use the scaling keys (+
and -), and FOF.EXE locks up on a few machines, all fast 486s. I haven't
heard of any problems with POLYDEMO.

In the first two cases, the problem is with clipping. Since polygon clipping
hasn't been introduced at that point in the book, it's not used in those
programs, and it's needed. <g> Unfortunately, I didn't trap out all cases
where polygons could run off the virtual screen and trash memory. As for the
FOF.EXE lock-up -- we aren't sure yet what causes it. Two possible clues: it
only seems to happen on fast 486s without joysticks and/or gameports; and
some people have reported that the problem clears up if they install the
program a second time. Does your machine have a gameport? And have you tried
reinstalling? If you do reinstall, I'd recommend clearing up a little extra
disk space, in case it's some kind of out-of-memory error. How much free
space do you have on that drive, BTW?

Any insights you may have as to what's causing the FOF.EXE lock-up would be
appreciated, since we haven't been able to duplicate it. When we do, we're
going to make a fixed version available. Thanks for the report!

--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 353865
To: Jeff Ross 71561,3161                       Date: 13-May-93  05:14:42

Jeff:

You're correct about everything except the bitmap compression. The cockpit
bitmap is compressed only once, when it's initially loaded into memory, and
is stored in a buffer. It remains compressed (without being recompressed) for
as long as the program continues running. For each individual frame of the
animation, a decompressed version of the bitmap is drawn over top of the 3D
view, with the view showing through the transparent portions of the cockpit.
(The decompression is performed by the Ctransput() function, described in
Chapter Fifteen.)

The reason that the cockpit is maintained in compressed form is that it can
be moved to the video display much faster that way, without transparency
checking (and transparent pixels can simply be skipped altogether). In an
earlier version of the code, we maintained the bitmap in uncompressed form
and it ran _unbelievably_ slow! Compressing the cockpit bitmap more than
quadrupled our frame rate, if I recall correctly.

--Chris
...........................................................................

Fm: Rasputin 71005,2524                        # 358678
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 19-May-93  23:52:44

Chris, after several people in this forum recommending your book to me (FOF), I
finally got it (It was a birthday present from my mom!). anyways, I was
pondering the Idea of the Z buffer, and came up with a theoretical solution
to make it faster, and possibly faster than the painter's algorythm (sp?)
anyways, it goes like this ... Instead of storing the Z for each point, store
the Z for a run of points... presumably in the polygon drawing routine... and
don't actually plot those points at that time, store them in an array of line
runs... when a lower Z comes along, you could perform surgery on the array as
necessary to reflect the changes(leaving the pixels that weren't covered, and
modifying longer runs that were covered only in the middle. then when it
actually came time to draw the runs, you could compare them with the array of
runs that you drew for the previous screen, tand avoid redrawing long runs of
pixels, thereby bypassing the need to erase the old screen, or draw large
areas of the screen that didn't change...  I know that my explanation of the
theory I have formulated is kind of sketchy... do you get where I'm coming
from? any and all responces welcome.

                                Dan Kelly.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 359234
To: Rasputin 71005,2524                        Date: 21-May-93  00:53:08

Dan:

Interesting idea, but I'm having some trouble visualizing how the Z runs
would be stored. I assume they'd need to be horizontal runs, since that would
optimize the actual drawing of the pixels when the time came to do so. But
that means one end of the run could have a different Z value from the other,
since there's no guarantee that the run will be parallel to the display
plane. So the structure would need to be designed to store at least two Z
values for each run in a way that would allow fast comparisons between
overlapping runs. The main problem might be quick identification of
overlapping runs -- i.e. how do you rapidly determine which old run to
compare a new run against? Perhaps with a binary search of some kind? If you
could find a way to organize the structure efficiently (as some kind of
tree?), it might be more accurate than an unaugmented depth sort and faster
than a complete Z buffer. Could be worth thinking about in more detail.

Come to think of it, there's a hidden surface removal technique called the
scan-line method that I ran across while writing FLIGHTS OF FANTASY that's
similar to what you're describing (or at least to the way I'm visualizing
it). I haven't really studied it and can't pretend that I understand the
details, but if you've got access to a copy of Hearn and Baker's COMPUTER
GRAPHICS (my favorite reference when I was writing FOF), it's discussed on
pages 264-265. It involves performing a separate sort of polygon edges for
each scan line in the viewport. My superficial impression is that it would be
too slow for realtime animation on current generation processors, but might
be similar to the way your Z run method would work in practice and could be
superior to the Z buffer in some circumstances. You might want to check it
out to see if it gives you some ideas.

--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 363026
To: All                                        Date: 26-May-93  04:56:35

Those of you have encountered the mysterious lock-up problem with the FOF.EXE
flight simulator that comes with my book FLIGHTS OF FANTASY (where the sim
locks up immediately after the opening title screen) will be happy to know
that Mark Betz and I located the source of the problem last night. I'll be
uploading a fix as soon as Mitch Waite and I decide on what form the fix
should take. For now, you can fix the problem yourself if you have the BC++
compiler (or TC++ and TASM). In module AIRCRAFT.CPP, change line 544 from

  loopTime /= 1000;

to

  if (!(loopTime /= 1000)) loopTime = 1;

and recompile FOF.EXE.

This _should_ fix the problem. (It avoids a Divide by Zero error later in the
code that apparently only occurs on fast machines without joysticks or sound
boards to slow down the simulator's initial loop timing calculations.) If it
_doesn't_ fix it, let me know right away. Thanks!
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 365830
To: Ian Christie 70534,403                     Date: 30-May-93  21:56:29

The fix for the FLIGHTS OF FANTASY lock-up bug that occurs on some fast
machines is to change line 544 of AIRCRAFT.CPP from

  loopTime /= 1000;

to

  if (!(loopTime /= 1000)) loopTime = 1;

and recompile FOF.EXE.

Let me know if that works for you.

--Chris
...........................................................................

Fm: Paul Whittemore 72007,3305                 # 367865
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 02-Jun-93  19:45:16

Just found my first FOF bug...  Try pulling back until you're inverted and
look out either side.  As you cross the 90 degree mark you'll see a weird
'flash'.

But even if you miss this, while flying inverted, pull back.  This should
send you toward the ground.  It does, but in the side views, the pitch is
reversed so it *looks* like you're climbing inverted.  Eventually, you'll
crash, but the view indicates climbing.

Got some more FOF reading to do or I'd find the offending line right away.
(Don't wanna get dirty ... yet.)

Paul
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 368104
To: Paul Whittemore 72007,3305 (X)             Date: 03-Jun-93  03:42:38

I'm familiar with the "flash" bug. I chased it for a while but never caught
it. Finally, I just left it in. Ultimately, the problem has to be in the
draw_horizon() function, though it might be triggered in turn by something
earlier in the code. That's where to start looking, though. That function,
which draws the sky and ground background colors, was the second most
difficult part of the code to write. (Hidden surface removal was the
hardest.) Took at least two weeks to get that one function working properly.
And still, under certain conditions, the sky and ground magically reverse.
(That's what causes the flash.) It only happens for a single frame at a very
few orientations and I never was able to figure out why. If you do, be sure
and let me know.

I hadn't noticed that problem with the side views. I remember how crazy Mark
and I went figuring how to calculate the side views, so obviously we missed
something. I'll try that and take a look. Once again, if you find the cause,
let me know!

--Chris
...........................................................................

Fm: Hans Peter Rushworth 100031,473            # 368718
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 04-Jun-93  00:42:42

Mark,

>> Does it handle the view orientation correctly from all angles?

Yes, It works right off the rotation transform matrix, so whatever
combination of heading/pitch/bank/yaw etc is automatically catered for. It
still has the obligatory 16-way switch, of course. <g>

I'll see if it's in a state to post, if not I will email it...

Peter.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 368686
To: Hans Peter Rushworth 100031,473 (X)        Date: 03-Jun-93  23:55:24

Actually, I would kinda like to see that horizon routine, if you'd still like
to send it on. It could be useful to see how you approached the problem,
assuming you've made some changes from last summer's version.

--Chris
...........................................................................

Fm: Hans Peter Rushworth 100031,473            # 368908
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 04-Jun-93  11:11:15

Chris,

I'll email you the full version, the trick is how to calculate window
intercepts and decide upness. The following is a brief explanation of how it
works, that I wrote at the time to our project supervisor. You can tell from
this that I was extremely pleased with myself. <g>

____________
(28-November):

Using the equation for the horizon plane and plugging the values for the
window edge vectors into it will give a unique solution for the window
intercepts. The equation of the horizon plane comes directly from the plane
normal, which is the 3rd column in the CTM. For Example, after some
re-arrangement, the equation that gives the Y value of the right window edge
intercept (when valid) is simply

 -((a + c) * height of window)/b) where [a] is the 3rd column of the CTM.
                                        [b]
                                        [c]

(if b is zero, it means that the horizon is outside the window, you test
for this first obviously).

The other intercepts are similar.

Whats more, the question of "up" is solved by examining the sign of just one
co-efficient in the matrix. (actually there is one case where you need to
distinguish left from right, which just uses a different co-efficient of the
matrix).

When I looked at this first I thought it was so simple it could NEVER work.

Surprise surprise. I can now calculate the intercepts of the horizon with
the window edges for **_ANY_** orientation DIRECT from the CTM with ZOOM and
SIZE/SHAPE taken into account In FOUR LINES of code. No trigonometry, mammoth
overloaded behind your back matrix operations either. I am amazed. To think
that I slaved for hours over trig methods and couldn't get it to work
before, when this method is so direct and simple.

So anyway, the horizon works now.
__________

Peter.
...........................................................................

Fm: Jeff Ross 71561,3161                       # 368063
To: Chris Lampton 76711,301 (X)                Date: 03-Jun-93  01:14:34

Chris,
        Help.  I've tried several times to change the NUMBER_OF_DEGREES in
the SIN/COS tables but have had no luck.  Generated 360 and 300 degree tables
using makesine.cpp and then incorporated them into the project. All rotations
are very jerky and unusable.
        Thought the problem might have been in the mapangles routine in
DrawHorizon, but, that didn't help.  For instance; with either of these new
tables and rotating around the y axis (yaw) it will move for roughly 2-3
degrees and then jump back, then if I keep pressing the key it will suddenly
jump a whole bunch of degrees in that direction.
        Do you think it may be a problem in actually generating the tables in
Makesine.cpp? It seems pretty straight forward.  Perhaps in the Fixed-point
usage?  I'm new to this 'Fixed-point' stuff so I could be missing something
here. I realize it's probably something very minor/obvious but I cant' seem
to see it.  I figure you had a reason for 256 degrees and maybe you could
steer me in the right direction.


As always, thanks
Jeff
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 368088
To: Jeff Ross 71561,3161 (X)                   Date: 03-Jun-93  02:24:43

I was afraid of that. I never tried changing the number of degrees myself, so I
really don't know if it could be done that easily or not. As I said in an
earlier note, I may have assumed the 256 degree system somewhere in the code.
I'll take a look through it and see if I can locate the assumption. It's
probably in the view system somewhere, since Mark uses a different rotation
system altogether in the flight model. Might just be a matter of making
simple changes to the code. I'll get back to you on it.

--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 368101
To: Jeff Ross 71561,3161 (X)                   Date: 03-Jun-93  03:42:23

Okay, I think I may have found the problem. It's not in the FOF source code,
but in MAKESINE.CPP, in the lines that write the SIN and COS macro
definitions to the header file. These macros return a value from the sine and
cosine arrays declared in FIX.CPP, first ANDing the array index with the
NUMBER_OF_DEGREES minus one. (This is a fast way of getting the index modulo
the number of degrees, as long as the number of degrees is a power of two.)
I've hardcoded a 255 here. Rewrite this so that it will AND the index with
the value of NUMBER_OF_DEGREES minus one. And be sure the new number of
degrees that you choose is also a power of two (i.e. 512, 1024, 2048, etc.).

If this is confusing, let me know, and I'll send you specific code.

--Chris
...........................................................................

Fm: Jeff Ross 71561,3161                       # 368569
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 03-Jun-93  21:33:13

Chris,
      Okay! Great! I thought it might have been in Makesine.cpp but it all
      looked fairly straight forward to me. I guess I didn't look very
      hard since it was a short routine.

      So, if I get you:

      Change ... const NUMBER_OF_DEGREES = 1024 // for example 1024 degrees

      Change ...cos_table[ABS(X)&1023]...
             ...sin_table[ABS(X)&1023]...

      I'll try this out probably friday and let you know. Also, I'm
      basically, so far, using the book as defined in chapt 15, interfacing
      the View system. No code for flight model etc since I'm going in a
      different direction here.  Have noticed that when I translate my
      position beyond a certain point I seem to 'wrap' back around in the
      world database.  Doing a straight increment of the curview.copx/y/z
      values until I get my flight model hacked out. Haven't had a chance to
      dig into this yet but before I do, is that the way it was intended?
      The version I'm running uses your code as is, no mods at all, and the
      world database that came with it "FOF2.WLD". Didn't see any mention of
      this in the text.

Again, many, many thanks.  I'll get back to ya, Jeff

PS: Must thank you again for writing the book! As I've said before I've been
trying to write a flight sim since I created my first "hello world!" program
n QBasic.  You've saved me probably 6 months of work.  My only problem now is
that a little information is becoming dangerous. I find I spend so much time
coming up with algorithms and ideas for features (since I now have an
"engine" for showing them) that I have a tuff time sitting down and putting
the whole thing toghther!  This is fasinating to me.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 369081
To: Jeff Ross 71561,3161                       Date: 04-Jun-93  17:16:57

Yes, that's exactly what you need to do to change the number of degrees. (I
see from your next note that you got it working, but I was too tired
yesterday to respond to most of my messages so I'm responding to the earlier
one instead. <g>) The wraparound is discussed in the Appendix and in the
README file on the disk. It results from the fixed point routines, which only
allow 14 bits precision to the left of the decimal point. Hence, there's an
automatic coordinate wrap at position 16384 on any axis. If you want to
rewrite the fixed point as a function or overloaded operator using 386
registers, you can improve this considerably. There would still be limits. A
commercial sim would load a new database before wrap occurs, but FOF.EXE
isn't that sophisticated.
--Chris
...........................................................................

Fm: Paul Whittemore 72007,3305                 # 369269
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 04-Jun-93  22:24:24

Although I said I was going to finish the book first, I spent some time last
night looking at the horizon problem with inverted side views.  (Since I
haven't gotten to the corresponding chapter of the manual yet, you can take
the following with a hunk o' salt.)

I don't think the problem is in the display_horizon method.  I think it's in
the caller (display).  In fact, it may be a more general problem related to
the inverted sign of Y coordinates.  And I think the horizon flash is related
to this problem, and may even be the same one...  (Just a feeling.)

The view is fine, except that the slope of the horizon needs to be negated in
the case of an inverted side view.  I tried forcing this, but realized the
*objects* were also moving in the wrong Y direction.  (With the correct
horizon, mountains would fly up into the air at the -angle that the ground
was moving away.  Since the problem is not limited to the horizon, it's not
*really* in draw_horizon.

I don't know about the world/view system yet to take it any further, yet. And
I wanna finish the book first, but I'll keep you posted...

Paul
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 369353
To: Paul Whittemore 72007,3305 (X)             Date: 05-Jun-93  00:33:55

No, I wouldn't expect to find the side view problem in draw_horizon() either,
though I'm pretty sure that's the place to look for the flash problem. I'd be
surprised if the two problems were related, though I could be wrong. (It's
been a while since I wrote this stuff, after all.)

The best place to look for the side view problem is in the ViewShift()
function. (See pages 524-525 in the book.) This is where we calculate the
change in view angle for views other than straight ahead on the viewer's
local z axis. Mark and I passed this function back and forth between
ourselves a couple of times before we got it to work properly -- and we may
still have missed some special cases. Check it out and see if you can see
what we might have missed. It always helps to have fresh eyes look at the
code. The case statement on page 525 cycles through the right, back and left
views -- or is it the other way around? Hey, Mark!
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 372824
To: Paul Y. Chong 72762,2775                   Date: 10-Jun-93  01:17:04

Paul:

The FOF lock-up problem is triggered by a divide-by-zero error in module
AIRCRAFT.CPP. It only occurs on fast machines, usually without a sound board
and/or joystick to slow things down, which is why we missed it when putting
the program together. If you've got the BC++ compiler you can fix it with a
simple change to the code. Change line 544 of AIRCRAFT.CPP from

  loopTime /= 1000;

to

  if (!(loopTime/=1000)) loopTime = 1;

Let me know if that works. Good luck!

--Chris
...........................................................................

Fm: Paul Whittemore 72007,3305                 # 376168
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 14-Jun-93  18:57:59

I noticed some minor improvements: like the blitting was done 32-bits at a
time (STOSD rather than STOSW) and I used incremental offsets in one loop
(from Ch. 9) rather than multiplication.  (Things like that.)

BTW:
I've more or less decided to do a *new* flight sim since I don't want to have
to worry about legalities and other people's priorities, but one heck of a
lot of the effort could be applied to FOF as well.  A complete 386 assembler
fixed point library, network/modem support, external views, enemy planes,
weapons, other moving objects (e.g. ground vehicles), variable altitude
ground level, textured ground and my potential plan for bitmap-wrapped
objects.  It could all be added to FOF as it becomes available without
compromising my project (if it ever materializes).
...........................................................................

Fm: Paul Whittemore 72007,3305                 # 378921
To: LYNN L. HOWARD 71054,3050                  Date: 18-Jun-93  20:27:43

I tried recompiling the FOF source with -3 and my times dropped from
44 ms/f to between 36 and 39 ms/f.  I've written the necessary 386 32-bit
fixed point routines, except for division.  (The book says only addition,
subtraction and multiplication are necessary, but the source says
otherwise.)  There are several initialization-time conversion functions
required too, (and their also done), but I don't think they're needed per
frame.  I'm going to take a stab at complete replacement for all the
float/double and 16-bit fixed point math as soon as I get a chance.  I'll
keep everyone informed of any performance gains I can get.

Thanx,
Paul
...........................................................................

Fm: Andrew Amess 100141,1567                   # 378691
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 18-Jun-93  14:19:12

Hi, interested in your comments about buffer moves to VGA. I am currently
writing games for the 386 and above which have 9 and more levels of parallax.
I can upload some early demos, which look rather good.
Anyway, about block moves, I have an idea and tried it out but didn't profile
it, maybe it will ring some bells.
I interleaved the move bytes to VGA code with move 0's to the system ram
video buffer wondering if the processor would do the blit/clear loop quicker.
A friend said yes it should because whilst the data is going down the bus you
can be writing to system RAM.
Also, where can I find chit chat on optimising code as I need every cycle I
can get my hands on at the minute.
TIA.
Chris Nurse (Using Andrew Amess account).
...........................................................................

Fm: Andrew Amess 100141,1567                   # 379165
To: Paul Whittemore 72007,3305 (X)             Date: 19-Jun-93  09:19:54

With the fixed point matrix multiplier, which I have also done in assembler:-
To divide matrices do I just change my IMUL to a DIV etc...
I have a rather nice assembler version which uses a macro and have unrolled
the whole multiplication so you can get something in excess of 4500 complete
operations per second; Is that good? I have nothing to compare against as I
am not heavily into FOF code but the book has proved to be a gold mine since
the day I got it!
...........................................................................

Fm: Paul Whittemore 72007,3305                 # 380186
To: Andrew Amess 100141,1567                   Date: 20-Jun-93  20:53:04

> With the fixed point matrix multiplier, which I have also done in
> assembler:- To divide matrices do I just change my IMUL to a DIV etc...

With both the multiplication and division, it's not that simple if you don't
want to lose much accuracy.  With fixed point 32-bit division, the simple
division results in a complete loss of the fractional part (37/4= 9.000).
I'm planning on shifting the numerator left by as many places as there are
high zero bits (up to the number of bits to the right of the fixed point).
Then shift the denominator right for the difference.  This should maximize
precision without changing from a single division.  There are other methods
I'm looking at, too.  For multiplication, I'm looking at detecting overflow
and returning 0x7FFFFFFF (my 32-bit fixed point numbers are signed) which
should be good enough for 'fuzzy' accuracy like flight simulators.  I want
to prevent wrap while still allowing the large numbers to be multiplied
together.

I haven't had enough time yet to really look at it, but when I finish off
the routines, I'll post them for general use.  They're BC++ and TASM and
assume a 386+ for the 32-bit accuracy.

Regarding your routines: it doesn't sound like 32-bit accuracy if you can
implement them in a macro.  I don't have any idea about the performance
yet, so I can't say whether you numbers are good or not...

Paul
...........................................................................

Fm: Eric Klein 72302,2731                      # 381056
To: Mark Betz 76605,2346 (X)                   Date: 21-Jun-93  21:45:31

The FOF program from "Flight of Fantasy" book, hangs afters the initial
credit. I am using a local bus DX2-66 with "Diamond Stealth 24" local bus
video card.

Running FOF with "D"(debug) parameter gives a message "floating point
error:Domain" and then hangs.

Debuging through FOF it seems to crash in the image routines.

Any ideas of how to solve this problem?
Also where could I find the lastest source for FOF?

FOF runs fine in a compaq DX2-66 with Q-Vision video.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 381152
To: Eric Klein 72302,2731 (X)                  Date: 21-Jun-93  23:29:48

Eric:

The FOF simulator sometimes locks up on fast 486s, especially if they lack a
SoundBlaster and/or joystick to slow down the code. If you've got BC++,
change line 544 in module AIRCRAFT.CPP from:

  loopTime /= 1000;

to:

  if (!(loopTime /=1000)) loopTime = 1;

and recompile. That should fix the problem.

I plan to upload the fixed EXE file to LIB 11 here within the next couple of
days.

--Chris
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 381476
To: Eric Klein 72302,2731 (X)                  Date: 22-Jun-93  12:33:18

Hi, Eric. We had a problem with the program on very fast machines, often
those with neither a sound card or a joystick, which caused it to lock up
right after the opening screen with a FP domain error (divide by zero).
Essentially what is happening is that on these machines it takes less than 1
millisecond to get from the point in initialization where the timer is
started to the point in the flight model where it is read for the first time.
Since the elapsed time in microseconds is divided by 1000 to obtain
milliseconds, this situation results in an elapsed time in milliseconds of 0.
This is then used as a divisor in parts of the flight model, causing the
error. The author is getting ready to make the new version of the executable
available here in Game Design, but in the meantime the fix simply requires
making sure that loopTime cannot have a value of 0 on the first pass.

                                                        --Mark
...........................................................................

Fm: Paul Whittemore 72007,3305                 # 382526
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 23-Jun-93  19:36:54

> I plan to upload the fixed EXE file to LIB 11 here within the next couple
> of days.

You may want to consider uploading one recompiled with -3 also, since the
performance improvements are reasonable...  Just a thought.

Paul

P.S.  Still working on a complete replacement with 386-specific 32-bit
      fixed point, but I have a (work) deadline of Friday and I move on
      Tuesday so I've had to postpone it temporarily while I work like
      a dog...
...........................................................................

Fm: Eric Klein 72302,2731                      # 382399
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 23-Jun-93  16:12:00

I recompile with your change and it works now.
Thanks for your quick response.

                Eric
...........................................................................